Micron Document
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| SparkN0de-git | SparkN0de |
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------


Displaying Raw • View renderedDownload


SECURITY.md dev (b5f9665d) Text, 7.98 KB

Tc9d1d9# Security Policy

Tc9d1d9## Reporting a vulnerability

If you believe you have found a **security vulnerability** in MeshChatX, please report it privately so it can be fixed before wider disclosure.

**Preferred contact (in order):**

Tff7b721. **LXMF**: Ta5d6ff`f489752fbef161c64d65e385a4e9fc74`

Include enough detail to reproduce or understand the issue (what version or build you used, what you expected, what happened). Do not open a public issue for unfixed vulnerabilities.

**Not security (legal, licensing, general questions):** Ta5d6ff`legal@quad4.io` or see [Ta5d6ff`LEGAL.md`](LEGAL.md).

---

MeshChatX is meant to be used on **trusted networks** (for example at home, on a LAN, or over a VPN you control).

If you still put the web interface on the **public internet**, you accept much higher risk (password guessing, misconfigured TLS or proxies, automated scanning, and overload of a single-node app). If you must expose it: **turn on authentication**, use **HTTPS** with a valid certificate for the public name, **restrict who can reach the port** (firewall, VPN, or a reverse proxy with sensible rules), and **keep the application updated**. Ta5d6ff`/robots.txt` with Ta5d6ff`Disallow: /` is only a hint to crawlers, not protection.

The app adds **rate limiting** and **lockout** for failed logins, **logging** of access attempts (viewable under Debug Logs), and **HttpOnly** session cookies with **SameSite=Lax**. These measures reduce some abusebut do not make a public deployment “safe by default.”

Tc9d1d9### What you download should match what we built

Official release binaries and packages are built in **automation on GitHub**, not by hand on a laptop. Each tagged release is intended to ship:

Tff7b72- **Installable files** (for example AppImage, Ta5d6ff`.deb`, Windows and macOS installers, Python wheels) from that tag.
Tff7b72- A **software bill of materials (SBOM)** in CycloneDX form (Ta5d6ff`sbom.cyclonedx.json`) where the Linux release pipeline produces it, so you or your tools can see what went into the build.
Tff7b72- **Signed provenance** files (Ta5d6ff`*.intoto.jsonl`) that cryptographically tie those binaries to the **same source repository and tag** on GitHub, using the industry [Tff7b72SLSA](Te6edf3https://slsa.dev/) approach and the [Tff7b72slsa-github-generator](Te6edf3https://github.com/slsa-framework/slsa-github-generator) project. New tags also get a **draft** GitHub release so assets can be reviewed before the release is published.

**Docker images** published to GitHub Container Registry are built in CI and **signed with Cosign (keyless / Sigstore)** so the signature can be checked against the image digest.

**Optional extra signatures:** If you see Ta5d6ff`*.cosign.bundle` files next to a binary, those are additional attestations from a **repository-managed signing key** (when the project enables it). They are separate from the SLSA Ta5d6ff`*.intoto.jsonl` files. Either or both may be present depending on configuration.

Tc9d1d9### Source tree integrity (`.rsm`)

The repository root includes a signed rnid message file, Ta5d6ff`meshchatx.rsm`. It embeds a SHA-256 inventory of git-tracked files except itself and paths under any Ta5d6ff`vendor/` tree. CI verifies the signature against the required signer identity Ta5d6ff`e46112d44649266d71fe2193e00a4710`, then re-hashes file bytes. Jobs also recheck the inventory at the end so a compromised runner cannot silently add or modify tracked files.

Verify locally:

Ta5d6ff```Ta5d6ffbash
make tree-rsm-verify
Ta5d6ff```

Maintainers regenerate the signature after intentional tree changes (requires a private identity file that hashes to the signer above, never commit Ta5d6ff`*.rid`):

Ta5d6ff```Ta5d6ffbash
Tffa657export Te6edf3RNS_ID_PATHTff7b72=Ta5d6ff"Te6edf3$HOMETa5d6ff/.local/share/reticulum-go/reticulum-go-release.ridTa5d6ff"
make tree-rsm-sign
Ta5d6ff```

Enable the tracked pre-commit hook so commits that change inventory paths resign Ta5d6ff`meshchatx.rsm` automatically when that identity is available:

Ta5d6ff```Ta5d6ffbash
make hooks-install
Ta5d6ff```

Skip one commit with Ta5d6ff`SKIP_TREE_RSM_HOOK=1`.

Tc9d1d9### Practical tips

Tff7b72- Prefer **official download pages** or **GitHub Releases** for your copy of the app.
Tff7b72- For Docker, prefer an image referenced by **digest** (Ta5d6ff`@sha256:…`) once you trust a given build, not only by a moving tag.
Tff7b72- If something claims to be MeshChatX but does not match published checksums or verification steps, treat it as **untrusted**.

---

Tc9d1d9## For security professionals and auditors

Tc9d1d9### Product controls (high level)

Tff7b72- **Desktop (Electron):** Packaging and runtime follow [Tff7b72Electron security guidance](Te6edf3https://www.electronjs.org/docs/latest/tutorial/security). ASAR integrity and hardened defaults (for example fuses that reduce risky Node integration) are part of the shipped app.
Tff7b72- **Backend:** A SHA-256 manifest of the bundled Python backend is checked on startup to detect tampering with the on-disk payload.
Tff7b72- **Data at rest:** The application can detect unexpected changes to sensitive files between runs (integrity monitoring around identities and database state).
Tff7b72- **Web surface:** Content Security Policy is applied in depth across the stack.
Tff7b72- **Containers:** Images are intended to run **without root** inside the container where the platform supports it.
Tff7b72- **External code (SRI):** Any WebAssembly or external JavaScript loaded at runtime (micron-parser-go, Codec2, RNode flasher libraries) is verified with **SHA-384 Subresource Integrity (SRI)** before execution. If a hash mismatch is detected, the code is blocked and an error is thrown. This prevents a compromised or malicious WASM binary (for example, a keylogger) from running even if an attacker replaces files on disk.

Tc9d1d9### Build, supply chain, and transparency

Tff7b72- **CI:** Automated pipelines (hosted on GitHub Actions) run dependency and configuration scanning (including **Trivy** and **pip-audit** on relevant paths), build checks, and security-relevant automated tests (authentication, path safety on dangerous operations, schema upgrades, backup/restore, rate limiting and access logging, and related areas). SRI integrity tests verify that external WASM/JS files match their declared hashes without regenerating the integrity manifests. CI will fail if you update these files without regenerating the integrity manifests.
Tff7b72- **Action pinning:** Third-party GitHub Actions are referenced with **pinned commit SHAs** in workflow definitions to reduce unexpected upgrades.
Tff7b72- **Releases:** Tagged release artifacts for Linux, Windows, and macOS are produced in CI. When the pipeline also produces Android APK and/or Flatpak bundles for the tag, those binaries are included in a separate **SLSA** attestation (Ta5d6ff`meshchatx-android-flatpak-<tag>.intoto.jsonl`). **SLSA Build Level 3-style provenance** for those subjects is generated via the **generic** SLSA GitHub generator (Ta5d6ff`generator_generic_slsa3.yml` at release **v2.1.0**, with Ta5d6ff`compile-generator: true` so the builder is compiled from that tag rather than downloaded), which satisfies the **isolated builder and signed provenance** expectations for that tier. **Distribution** (draft releases, mirrors) and **consumer verification** remain your operational controls, as described in upstream SLSA documentation.
Tff7b72- **Transparency logs:** Many Sigstore flows write to the **public Rekor** log (Ta5d6ff`https://rekor.sigstore.dev` by default). **Repository-key** Ta5d6ff`*.cosign.bundle` files next to release artifacts are built **without** a Rekor entry; with **Cosign v3+**, verify them against Ta5d6ff`cosign.pub` using Ta5d6ff`cosign verify-blob-attestation` and Ta5d6ff`--insecure-ignore-tlog=true` (signature and predicate are still checked against the public key). Private-repo or air-gapped policies may require different Sigstore settings; operators should align Ta5d6ff`COSIGN_REKOR_URL` and related variables with their own governance.
Tff7b72- **Cosign public key:** When repository key-based signing is used, the **public** key is published in-repo as Ta5d6ff`cosign.pub` so verifiers do not need a separate out-of-band key hunt. **Key rotation:** replace the GitHub secret holding the private key and update Ta5d6ff`cosign.pub` in the repository; older releases remain verifiable with the key that was current at build time.


──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────